In cryptography, a public key infrastructure (PKI) is an arrangement that provides for trusted third party vetting of, and vouching for, user identities. It also allows binding of public keys to users. This is usually carried out by software at a central location together with other coordinated software at distributed locations. The public keys are typically distributed in public key certificates (PKCs) that are usually distributed by a Certificate Authority (CA). PKI arrangements enable users to be authenticated to each other, and to use the information in identity certificates (e.g., each other's public keys) to encrypt and decrypt messages. In general, a PKI consists of client software, server software such as a Certificate Authority, hardware (e.g., smart cards), and operational procedures. A user may digitally sign messages using his private key, and another user can check that signature using the public key contained in that user's certificate issued by a Certificate Authority within the PKI. This enables two (or more) communicating parties to establish confidentiality, message integrity, and user authentication without having to exchange any secret information in advance.
Many enterprise-scale PKI systems rely on certificate chains to establish a party's identity, as a certificate may have been issued by the Certificate Authority computer whose ‘legitimacy’ is established for such purposes by a certificate issued by a higher-level Certificate Authority, and so on. This produces a certificate hierarchy composed of, at a minimum, several computers, often more than one organization, and often assorted interoperating software packages from several sources. For this purpose, a certification path validation algorithm may be used to verify that a given certificate path is valid under a given public key infrastructure. A path starts with the subject certificate and may proceed through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted Certification Authority.
Standards are critical to PKI operation, and public standards are critical to PKIs intended for extensive operation. Some of the standards for PKI infrastructures are provided by the IETF PKIX working group (PKIX-WG), for example as stated in RFC 3280 and related RFCs. However most of the PKIs do not follow exactly the RFC rule set. For example, RFC 3280 requires that all the PKCs that are CAs must have the Basic Constraint extension, and must assert the CA bit. If not, then the PKC can't be considered as a CA. Some of the intermediate CAs in Europe, for instance, may not follow this PKI rule and do not include any Basic Constraint extension within the PKC. Accordingly, such CAs may not be compatible with some RFC 3280 rules. Examples of other non-conformant PKC attributes may include Validity Dates, KeyUsage, Extended Key Usage, CRL Distribution Point, Authority Information Access, Subject Key Identifier, Authority Key Identifier, or Certificate Policy.
In order to accommodate non-compliant PKCs, some PKI engines may include configurability options for each capability where the PKIs can diverge from the RFCs. Users of such non-conformant PKI engines are then provided documentation explaining how to configure their application (manually) to accommodate or work around the non-conformant performance of the PKI engine. However, such manual configuration is undesirable for a variety of reasons.